1. Field of the Invention
The invention relates to a method for checking the integrity of data communications. The invention is particularly relevant in the context of data communications between two communication devices connected via a low bandwidth network.
The invention also relates to a communication device, in particular a smart card, embedding such a method.
2. Description of the Related Art
Communication devices are electronic devices comprising a communication interface. Examples of communication devices include smart cards, USB keys, dongles, Personal Digital Assistants (a.k.a PDAs), mobile phones, personal computers (a.k.a PCs), etc. Typically, such communication devices may be interconnected and communicate with others. For example, a mobile phone may comprise a game console and may allow its user to play games together with multiple other users of similar mobile phones, all mobile phones being connected to a game server or to a plurality of game servers.
Data typically need to be communicated in the form of data packets. A packet is a formatted block of information. A packet generally consists of at least two elements. The first element is a header, which normally marks the beginning of the packet and may contain communication information such as sending and receiving addresses. The second element is a data area (or payload), which contains the information to be carried in the packet. A third element of packet may be a trailer, which marks the end of the packet. The term “packet” is not always used. For example in the context of ISO 7816-3 smart cards the term APDU, for Application Protocol Data Unit, is used instead, at the level of the ISO 7816-3 protocol. However the actual formatting of the data communicated between two communication devices generally corresponds to the above definition of a packet. For example an APDU can be viewed as a packet. The use of packets is often required by the hardware equipment and/or low level protocols forming the communication interface. Packets are extremely useful when a large piece of data exceeding the capacity of the communication interface needs to be transmitted. In such case, data is divided into packets by the sending communication device and reconstructed by the receiving communication device. However, as will be seen more in details below, in the context of the invention, packets are preferably independent one from each other. Although certain types of packets can hold a lot of data (for example IP packets can contain several kilobytes of data), some applications rely primarily on packets containing a small payload. In such applications, each payload is typically independent, in the sense that it forms a logical unit of data, which is self sufficient. In other words, each such payload can be used by the receiving communication device without waiting for other data packets. Indeed, a logical unit of data is typically not broken up in small packets, but rather transmitted in a single packet, unless it is too big in which case it is typically broken up in several maximum size packets. This is due to the fact that there is an overhead for each data packet, therefore one typically tries to use as little data packets as possible. This is also due to the fact that breaking up a logical unit of data in multiple packets requires that the receiving communication devices reconstruct the logical unit of data from several data packets, which can be a tricky task. It should be noted that when a time critical logical unit of data is ready for transmission in the sending communication device, it is often sent immediately in order that the receiving communication device can use it as soon as possible, therefore the sending communication device typically does not wait until more data is available (which would have allowed to fill a bigger packet).
As well known in the art of telecommunications, communications between communication devices are typically prone to errors. Errors are not problematic in certain applications (e.g. a small noise in an analog telephone voice communication) but might have tragic consequences in other applications (e.g. real time transmission of an aircraft altitude to some navigation equipments). Depending on the type of data, errors may have different effects.
With certain types of data, which are referred to as fault resistant data, errors only affect the actual erroneous part of the data. For example, errors in an ASCII text document typically only affect the erroneous characters, and all others characters remain readable. Similarly, errors in uncompressed bitmap image only affect the erroneous pixels, while other pixels remain perfectly visible. Errors in uncompressed digitized sounds only affect the samples which bytes are erroneous, which creates a noise at the level of the sample when the sound is played.
On the other hand, certain data are very sensitive to errors. We refer to such data as fault sensitive data. For example, if a single bit of encrypted data is erroneous, the whole encrypted data is typically complete nonsense once decrypted, and sometimes it can't even be decrypted. If a computer file containing the binary code of a program has even a single bit wrong, it can prevent the program from running or render it unusable. Similarly, errors in certain compressed data (for example a ZIP computer file) typically result in the compressed data being corrupted and impossible to decompress properly, even if the errors only affect a negligible portion of the compressed data. The same is true for many computer binary files.
The error ratio in a data communication is the ratio of the number of incorrect bits (or symbols) to the total number of bits (or symbols) received. It is referred to as the BER, which stands for Binary (or Bit) Error Rate (or Ratio, depending on the authors) and has been subject to intense study by mathematicians, physicists and engineers over the last century. Different techniques have been devised not only to identify errors but also to correct them. Some techniques are generic (i.e. independent of the actual communication channel), for example error correction codes such as Reed Solomon codes, Viterbi codes, Turbo codes and the like, while others are specific to and/or optimized for certain communication channels (e.g. radio relay system in the HF band, satellite links, optical fibers, etc.). However, error correction techniques do not work above a certain BER. Conversely, in some data communications, the reliability is fairly high and the BER is statistically so low that no correction technique is implemented, in particular when the transmitted data are not critical.
Therefore errors may happen from time to time and remain unnoticed in most data communications.
Another known problem with data communications taking place over a network such as the Internet network is the following. Not all packets necessarily travel trough the same path when going from a sending communication device to a receiving communication device. Typically, devices known as routers decide how to route packets, i.e. which path the packet shall follow in order to reach its destination, based on different criteria, such as load balancing, network congestion, etc. Due to the fact that different path can be followed by different packets, the receiving communication device can receive packets in an order different from the order in which they were sent.
It is also possible that some packets are lost (they can be treated as erroneous packets, for example), or on the contrary duplicated (in which case it may be decided, for example, that the first one is taken into account and the subsequent ones are discarded).
Typically, the two main problems mentioned above, namely the packet errors and the wrong order of packets, are addressed by upper layer communication protocols.
For example, since the IP protocol does not deal with errors in the packet payload and with wrong packets order, it is possible to use the TCP protocol over the IP protocol (TCP/IP), which provides a reliable connection by detecting erroneous packets and asking the sending communication device to resend them, and by reordering the received packets. TCP uses a 32-bit sequence number that counts bytes in the data stream. Each TCP packet header contains the starting sequence number of the data in that packet, and the sequence number (called the acknowledgment number) of the last byte received from the remote communication device. With this information, a sliding-window protocol can be implemented.
Unfortunately, such upper layer protocols are typically complex and may consume more bandwidth than available. For example, the TCP header is at least 160 bits long, and may be longer in case optional fields are used. It is a serious impediment in an environment were the payload of the packets is small, e.g. of the same order as a TCP header. If the payload of an average packet is around 20 bytes, then TCP header alone (not considering the additional IP header, plus underlying low level protocols overhead) doubles the bandwidth requirement. Therefore, for many applications TCP is not appropriate. TCP is a complex protocol. In addition, with many TCP implementations, the application cannot access packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications such as streaming multimedia (for example Internet radio), real-time multiplayer games and voice over IP (VoIP) where it is sometimes more useful to get most of the data in a timely fashion than it is to get all of the data without any error.
In the Internet case, simpler protocols are available, for example UDP over IP, however UDP does not provide packet ordering, and does not manage erroneous packets although erroneous packets can be detected thanks to a CRC. UDP is not optimal either in terms of bandwidth consumption.